Tombstones are place holders for content on a remote device that have been deleted. When sync state is sent to a device requesting the current state of data held therein, the tombstone information, in addition to other data, such as newly added files or folders, or edited files, should be sent across as well, so that the remote device has an accurate representation of the latest sync state. An issue arises, however with respect to how long to hold on to tombstone data. The source device no longer has the content the tombstones refer to and—other than the fact that remote devices should be made aware of the deletions—has no reason to hold on to them. Each tombstone occupies a finite amount of space with respect to temporary and/or persistent storage; increases processing costs as each tombstone element is one more item that should be processed when servicing a sync state query request; and also increases the network transferal/communications by utilizing precious bandwidth space.
The most common scenario for mitigating this issue is the use of an expiration timer. After a set amount of time, tombstones are simply purged from the sync state database (DB). However, until the time of the purge, the DB may be holding tombstone state needlessly, thus, contributing to increased runtime costs. In addition, there may be a risk that the DB may be purged of tombstones prematurely—which may lead to sync state holes—or that the entire sync state DB has to be transferred to ensure that the consumer has an accurate representation of the device's sync state. Based upon the size of the DB, the latter's cost may be prohibitive.